feat(workspace): route warehouse tools through the bound workspace's engine - #1168

No actionable comments were generated in the recent review. 🎉

sequenceDiagram
  participant Session
  participant MCP
  participant Precedence
  participant NativeTools
  participant WorkspaceEngine
  Session->>MCP: Load live engine tools
  Session->>Precedence: Refresh routing for the session
  Precedence-->>Session: Return capability decisions
  Session->>NativeTools: Expose annotated native tools
  Session->>WorkspaceEngine: Expose annotated engine tools
  NativeTools->>Precedence: Check capability and warehouse
  alt Engine serves the capability
    Precedence-->>NativeTools: Return redirect
    NativeTools->>WorkspaceEngine: Route the operation
  else Local driver serves the capability
    Precedence-->>NativeTools: Return local verdict
  end

• Fix all pre-merge checks with AI

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands.}

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}

Review log

Stacked on #1167 — its review-log comment carries the attach contract (claims, disclosed residuals, review policy). This PR is reviewed the same way: a finding is a reproducible trace that violates a claim; rounds are capped.

Claims (in addition to #1167's)

1. Routing engages only when settledOutcome is attached and the configured datamate entry's pin names the bound workspace; any other outcome, or none, fails open with a stated reason.
2. Redirects are offered per materialised capability, never per warehouse type; a capability the engine did not materialise runs locally.
3. A redirect runs after the hard deny on destructive statements and after the write confirmation; it never executes anything itself; it is only offered to a caller whose agent may call the destination tool.
4. --integrations=local turns routing off for the session.

Disclosed residuals (in addition to #1167's)

• Routing is derived per turn; within a turn it does not re-derive.
• Beyond 256 tracked sessions the oldest is dropped and re-derived on its next call.
• A redirect can name a client another session removed; that is a tool-layer failure, not a query sent to the wrong warehouse.

End-to-end rows (from #1156, re-run on this stack 2026-08-28 against the demo workspace with a Snowflake connection; engine 0.7.0)

Rounds

(none yet)

Codex rounds

CI note — GitGuardian is red on this PR and that is a false positive. The "1 secret" is the literal placeholder github_pat_******** in the --token help text captured by packages/opencode/test/cli/help/__snapshots__/help-snapshots.test.ts.snap (a snapshot this PR regenerates). It was red on f68a41a8c before the marker-only commit too. Nothing to remediate; every other check is green.

@codex review against the numbered claims and the disclosed residuals in the review-log comment on this PR: report only a reproducible trace that violates a numbered claim; an instance of a listed residual is disclosed behaviour, not a finding.

Codex Review: Didn't find any major issues. Can't wait for the next one!

Reviewed commit: f68a41a8c1

Consensus review — minor, nit, and rejected findings

Companion to the inline review (6 major, no blockers). Panel: Claude + GPT 5.4 Codex, Gemini 3.1 Pro, Kimi K2.5, MiniMax M2.7, GLM-5.1, Qwen 3.6 — two convergence rounds. Reviewed against the numbered claims and disclosed residuals; instances of a listed residual are not reported.

MINOR

M0. Workspace identity drops the credential scope — precedence.ts:265-271, :419, :565 (inline)

Recorded as MINOR rather than the blocker the panel first ranked it. Each customer occupies a single tenant, so no customer can reach it; the only actor is an internal staff session switching tenants mid-flight, in a roughly one-turn window. Real defect, cheap fix, deliberately not scheduled — details and the ownership split with #1167 are in the inline comment.

M1. warehouse_list reports against a snapshot it never re-validates — warehouse-list.ts:28-46

It reads Precedence.forSession() and annotates rows with no binding check, while check() does re-validate (precedence.ts:565). After a mid-turn re-link the query tools correctly refuse the stale redirect and run locally with a notice, but warehouse_list goes on claiming those same connections are served by the old workspace — violating the invariant its own tests assert, that no surface claims a routing that will not happen. Expose the snapshot-validity check and use it before producing notes.

M2. Hardcoded engine-tool conventions fail silently — precedence.ts:81-87 (engineToolFor), precedence.ts:91-96 (INTEGRATION_TYPE)

Both are hand-maintained. A new engine integration (redshift), or a renamed engine tool (databricks_execute_sql → anything else), materialises normally and shadows nothing — the local call keeps running unaudited with no notice and no log line. Fail-safe, but silent, which is the one thing the module's opening principle rules out. A warning when a materialised *_execute_database_query-shaped key matches no known integration, plus a test asserting every INTEGRATION_TYPE value is a canonical DRIVER_MAP target, would make the drift visible. (The widest agreement in this review — four models raised it independently.)

M3. The dbt-fallback redirect names the fallback connection and offers no way to insist on dbt — precedence.ts:630-641

With a dbt project on DuckDB (known, unserved) and a served Postgres as the registry fallback, the call is redirected to datamate_postgresql_execute_database_query. Shadowing a served fallback is a deliberate fail-closed choice — the dbt attempt genuinely can yield nothing and land on that connection — so this is not mis-routing, and nothing executes. The problem is the message: it names the fallback connection as the thing the workspace serves, and the two ways out it offers are warehouse=<fallback> or --integrations=local. Neither lets the caller say "I meant the dbt path". Unreachable in production today given E2E row 5, so this matters when the dbt path is revived.

M4. resetDbtAdapter breaks the single-flight contract — register.ts:57-98

The finally clears dbtAdapterInflight unconditionally. If resetDbtAdapter() runs mid-flight it also clears it; the next call creates a new promise, and when the original settles its finally clears the new one. Test-only today, but a source of flakiness. Guard the clear: if (dbtAdapterInflight === mine) dbtAdapterInflight = undefined.

M5. Two coverage gaps CI cannot see — default-target.test.ts:62-84, :107, :113-120

The dbt-fallback tests are if (target.source === "dbt") {…} else {…} and the suite header notes it runs outside a dbt project, so the else always wins: adapterTypeFromManifest, the getAdapterType?.() / "unknown" coalescing and the construction of { source: "dbt", type, fallback } have no coverage at all. A branch-tolerant assertion cannot fail, so the gap is invisible. Given E2E row 5 the stakes are low — but then the module comments should say the dbt branch is currently dead rather than reading as if it is live.

Separately, "repeated resolution is stable and does not rebuild state" asserts only that three results match. It never counts adapter creations, so it does not test single-flight at all.

NIT

• The audit boundary covers three tools, not the warehouse surface. pii-detector.ts:135, schema/tags.ts:73,140, data-diff.ts:183-189, local/schema-sync.ts:84 and the FinOps modules reach Registry.get() and run SQL on the local connection with no precedence check. When the engine serves Snowflake, schema_detect_pii still runs unaudited against the same credentials. Not fixable here — the engine serves no equivalent capability — but worth stating as a known limit rather than leaving it implied.
• publishQueue keeps a settled promise per live session (precedence.ts:227,348-360). Three models called this an unbounded chain; it is one promise per session, replaced on each publish and bounded by MAX_TRACKED_SESSIONS, so there is no leak. Deleting the entry when the chain is still the tail is tidy-up, not a fix.
• --integrations=local is process-wide, not session-wide. index.ts writes process.env.ALTIMATE_INTEGRATIONS in middleware and it is inherited by child processes. Correct for the CLI; the comments consistently say "for the session", which is not what serve gets.

Additional missing tests

Beyond those named inline:

1. The same numeric workspace id under two credential scopes, with a mid-turn account switch.
2. Registry mutation between Precedence.check() and each dispatcher handler — default and explicit targets, all three ops.
3. An unattested engine in headless mode, asserting the result carries the fail-open reason.
4. A per-turn tools: { datamate_…: false } toggle.
5. A mid-turn re-link followed by warehouse_list.
6. A databricks redirect end-to-end is still worth having — only Snowflake and BigQuery are exercised.

(A previous version of this comment listed a followed schema_inspect redirect here, on the concern that <id>_get_table_stats might not return column metadata. Checked against the engine: snowflake_get_table_stats returns ColumnMetadata[] = {name, type, nullable, default_value, primary_key, unique_key, comment}, which is a superset of what native schema_inspect returns — the native handler hardcodes primary_key: false with a note that real PK detection "would need additional query". So the redirect is an upgrade, not a dead end, and the concern is withdrawn.)

Raised and rejected

Recorded so they are not raised again in a later round:

• "warehouse_list claims a routing the caller cannot follow." Wrong: warehouseListNote computes through servedFor, which filters on reachable. Covered by precedence.test.ts:463,468,488. (The real warehouse_list issue is M1 — a stale snapshot, not permissions.)
• "A hard-denied statement is redirected to the engine tool." Wrong as located: the deny throws before the guard runs, proved by precedence-guard-order.test.ts.
• "--integrations=workspaces silently evaluates to false." Wrong: yargs choices: ["workspace","local"] rejects the value at parse time.
• "An unguarded throw in Precedence.check() is only MINOR, since a tool crash is not a security boundary failure." Partly fair — the query does not execute — but it takes out sql_execute, sql_explain and schema_inspect together and contradicts the module's "undetermined runs locally and says so" invariant. Kept, folded into the TOCTOU finding on register.ts:476.
• A finding about the write confirmation not binding the eventual engine call. Withdrawn: the engine tool has been callable since feat(workspace): attach the bound workspace's engine as a derived MCP overlay #1167 and this PR does not touch the MCP execution path, so it is not this change's to answer.
• Session-id reuse after eviction resurrecting a stale announcement. Non-actionable with ULIDs.
• A determined-but-unserved dbt type being "routed to the wrong database." Downgraded to M3: the fail-closed choice is intentional and nothing executes; the defect is the message, not the routing.

What holds up

Worth saying, because seven independent reads converged on it: the design is right and the findings are all about seams.

• Guard ordering is correct and proved — precedence-guard-order.test.ts fails if the guard moves above the hard deny or the write ask. Most changes assert this in a comment; this one tests it.
• canonicalType inverting DRIVER_MAP instead of restating it, and deliberately keeping redshift distinct from postgres.
• The SERVING table making a new attach-outcome kind fail compilation until it is classified, with the safe default.
• The announcement machinery — announced vs publishing, the per-session publish chain, recording only confirmed deliveries. The tests cover the awkward interleavings: failed delivery, correction in flight, stop-before-announce-lands.
• Capability-scoped rather than type-scoped shadowing, with a test that sql_explain on BigQuery is not redirected to a tool that does not exist.
• annotate on every exit path including the error paths, where the marker matters most.
• The dbtAdapterInflight single-flight fix is a real bug fix independent of this feature.
• Only materialised datamate_* keys confer precedence; a declared-but-absent integration shadows nothing.
• The capability map is correct against the engine. Checked altimate-mcp-engine directly: Snowflake exposes execute_database_query / get_query_explain_plan / get_table_stats; BigQuery, PostgreSQL and Databricks expose execute only; databricks_execute_sql really does break the <id>_execute_database_query convention. INTEGRATION_TYPE, engineToolFor and the per-capability asymmetry all match what the engine actually serves, and the shared sqlAlchemyToolsBase adds nothing beyond execute + list. M2 is therefore a forward-looking maintainability concern, not a present mismatch.

Panel review disposition — 81d5e402f

Fixed (unit-tested; the user-visible change E2E-verified in headless run):

• unattributed and an unrecognisable named connection type now return an undetermined notice in the result instead of a bare RUN (deliberate disablement stays silent). E2E: bound sandbox, connection with an uncanonicalisable type, headless run — the result text carries the notice verbatim.
• check() fails open with a stated reason on any internal throw (covers the uncaught lazy import; all three SQL tools call it before their try blocks).
• A failed Config.invalidate() now refuses attribution (return null) instead of trusting the cached pin.
• resetForTests releases attachOutcome; the "same by construction" pin comment softened to what the pin actually guarantees.

Recorded as pilot residuals (per the review's own framing):

• credential-scope threading on workspace identity (single-tenant customers cannot reach it; the only actor is an internal session switching scopes mid-turn)
• per-turn tool-availability derivation for precedence
• TOCTOU: pin extension to explain/inspect and the atomic-lease redesign
• Config.invalidate() blast radius on the hot path
• attribution integration-test coverage (test debt, tracked internally)

Re-review of 81d5e402f

All six fixes land. Verified against the code and by reverting each one to see whether the suite notices:

Two of these are worth calling out as genuinely well done:

• Fixes 1 and 2 compose correctly. A failed invalidation now returns null → derive() records unattributed → check() states the reason. Claim 1 ("fails open with a stated reason") now holds on the path where it previously didn't, including headless.
• The notice actually reaches the caller. Deleting the notice-prepending in annotate() breaks tests, so the reason lands in the tool result rather than only in the verdict object or a toast.

The register.ts comment is now accurate about what the pin guarantees ("narrows, not closes"), and the guard-ordering and reachable() gating from the original review continue to hold. The routing code reads as ready.

One thing to fix first: three of this PR's tests fail when run alongside the rest of the directory

bun test test/altimate/default-target.test.ts                       ->  12 pass, 0 fail
bun test test/altimate/altimate-core-rewrite-verify.test.ts \
         test/altimate/default-target.test.ts                       ->  29 pass, 3 fail
bun test test/altimate/                                             -> 4381 pass, 3 fail

The three:

• the default target survives a concurrent registry change > a connection dropped during the dbt await does not silently redirect the call
• a connection replaced under the same name is not executed on the old verdict > a same-name replacement of a different type is refused, not run locally
• a connection replaced under the same name is not executed on the old verdict > a same-name rewrite that keeps the type still runs

Cause: altimate-core-rewrite-verify.test.ts:69,211 runs beforeEach(() => Dispatcher.reset()), which clears the process-global nativeHandlers map and the lazy registration hook (dispatcher.ts:35-41). Bun runs both files in one process, so default-target.test.ts — which imports Dispatcher but never re-registers — then fails with No native handler for sql.execute.

Why it matters more than ordinary flake: these are exactly the tests that prove the stale-connection guard, i.e. the concurrency property this PR adds. In any directory-wide run they don't execute, so that guard is currently unproven.

Fix: re-register in default-target.test.ts's setup, following the pattern already used in altimate-core-e2e.test.ts:158, altimate-core-native.test.ts:172 and altimate-core-stress-e2e.test.ts:38 — each carries the comment "Re-register handlers in case another test file called Dispatcher.reset()". Alternatively, have the rewrite test restore the handlers it clears.

Minor: two of the six fixes have no regression test

Reverting either leaves the suite fully green (111 pass, 0 fail), so both can regress silently:

• attributedTo's return null on a failed Config.invalidate() (precedence.ts:305). The attribution tests assign precedenceInternals.attributedTo directly, which bypasses the production implementation entirely — so the suite structurally cannot reach this path. Covering it needs an injectable config-read/invalidate seam. This is the security-direction fix (refuse rather than trust a stale "pinned to us"), so it's the one most worth protecting.
• The named unrecognised-type notice (precedence.ts:617). No test passes a named warehouse whose configured type doesn't canonicalise. A warehouse: "mystery" case asserting the notice and precedence: "undetermined" would cover it.

Nit

resetForTests() clearing attachOutcome is correct but untested — every current setup overwrites the seam immediately, so nothing would notice if the deletion were dropped again.

No new defect found in the routing logic itself. Ledger items from the previous round — credential scope, the config-cache blast radius, the remaining decision/execution window, per-turn tool toggles, the attribution test seam, and the hardcoded engine tool names (which check out correctly against the engine: Snowflake serves execute/explain/table stats, BigQuery, PostgreSQL and Databricks execute only, and databricks_execute_sql really does break the convention) — are treated as accepted and are not re-raised here.

Re-review disposition — a07d7b240

• Test isolation — fixed. The three concurrency tests dispatch sql.execute, which native/connections/register registers (re-registering core + sql the way the e2e files do left the three failing, so the target differs from the pattern while the comment is kept). default-target.test.ts now re-registers in beforeAll. Pair run altimate-core-rewrite-verify + default-target: 29 pass / 3 fail → 32 / 0; bun test test/altimate/: 0 fail apart from the pre-existing Trace.finalizeSync mtime-tie flake, which fails the same way on unmodified main.
• attributedTo refusal on a failed Config.invalidate() — covered through production. A precedenceInternals.config seam (get / invalidate) sits behind the real attributedTo; three tests: a pinned-to-us entry with a throwing invalidate derives unattributed; the same entry with a working invalidate attributes, with exactly one invalidation (positive control); a post-invalidate re-read pinned elsewhere refuses. Reverting the return null fails exactly the first.
• Named unrecognised type — covered. warehouse: "mystery" over { type: "weird" } (asserted non-canonical) → no redirect, precedence: "undetermined", notice names the connection and says "not recognised". Reverting the branch fails exactly that test.
• Nit — covered. resetForTests() releasing attachOutcome (and the new seam) is asserted.

Restacked once on the attach PR's 38788e419; bun test test/altimate/workspace/ + the pair above → 305 pass, 0 fail; tsgo --noEmit clean.

Disposition of the companion comment's minors — 1d1f3bc15

Now that the attach PR has merged, this PR is rebased onto main (base retargeted; same five commits) and the minor findings from the consensus review's companion comment are addressed in the new head:

• M1 — warehouse_list re-validates its snapshot. The binding re-validation check() did inline is exported as snapshotCurrent(precedence), and warehouse_list now annotates through warehouseListNotes(sessionID, warehouses), which returns no notes once the project is re-linked. Test (your missing test # 5): "warehouse_list stops claiming rows are served once the project is re-linked" — reverting the guard fails exactly that test.
• M2 — drift in the engine-tool map is visible. A materialised *_execute_database_query / *_execute_sql key from an integration the module does not know is warned once per session and shadows nothing (test: "an execute tool from an integration this module does not know is reported once and shadows nothing"); INTEGRATION_TYPE is exported and a test pins every value to a canonical DRIVER_MAP target ("every integration this module knows maps onto a canonical local driver type").
• M3 — dbt-fallback message. The redirect now says the call would try dbt first and, if dbt yields nothing, fall back to <connection> — and that the dbt path cannot be chosen from this tool; the routing decision is unchanged.
• M4 — resetDbtAdapter single-flight. A superseded attempt releases only the slot it owns (if (dbtAdapterInflight === mine)). Test: "a stale attempt settling does not release the slot a newer attempt owns" — fails without the guard.
• M5 — dead dbt branch. The suite header and the branch-tolerant tests now say the dbt branch is unexercised outside a dbt project; "repeated resolution is stable and does not rebuild state" and the concurrent-resolution test assert attempts === 1, so single-flight is actually tested.
• Nits: the audit boundary (three tools, not the warehouse surface — pii-detector, tags, data-diff, schema-sync, finops still run locally because the engine serves no equivalent) is stated in the module header; the escape hatch is documented as process-wide (process.env, inherited, serve included); publishQueue left as is per your note.
• Missing test # 6: "a databricks connection redirects execute to that tool, and nothing else" (execute-only, databricks_execute_sql convention).

Missing tests # 1 and # 4 stay with the recorded residuals they belong to (credential-scope threading; per-turn tool toggles); # 2 is covered by the existing default-target concurrency tests; # 3 by the annotate tests confirmed in your re-review.

Runs: bun test test/altimate/workspace/ test/altimate/default-target.test.ts test/altimate/altimate-core-rewrite-verify.test.ts test/altimate/tools/ → 501 pass, 0 fail; bun test test/altimate/ → 0 fail apart from the pre-existing Trace.finalizeSync mtime flake; tsgo --noEmit clean.

@codex review against the numbered claims and the disclosed residuals in the review-log comment on this PR (and the attach contract it references): report only a reproducible trace that violates a numbered claim. Instances of the disclosed residuals are not findings. Since your round 1 on 83c50756e this head adds: the panel fixes (undetermined notices in the result, check() failing open with a stated reason, attribution refusing on a failed invalidation), production-path attribution tests, the review's minors (warehouse_list re-validating its snapshot, the engine-tool drift warning, the dbt-fallback wording, resetDbtAdapter single-flight), and a rebase onto main after the attach PR merged. A round with no claim violation ends review.

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Code Review Summary

Status: No Issues Found | Recommendation: Merge

_{Reviewed by deepseek-v4-pro · Input: 81.4K · Output: 19.2K · Cached: 745.2K}

_{Review guidance: REVIEW.md from base branch main}

Round-2 disposition — 6ab901fcd

Codex (round 2, scoped against the contract) found two real ones; both fixed. Kilo, CodeRabbit and cubic each added items on the same head; the ones with a reproducible defect are fixed, two are declined with reasons on their threads.

Fixed

• Materialisation is owned by the engine's MCP client, not by the datamate_ prefix: a foreign server named e.g. datamate_snowflake flattens to the same key shape; such keys now confer nothing and are warned once per session (codex P1, cubic).
• An unreadable workspace link settles binding-unreadable — undetermined with the reason in the result, and it invalidates a routed snapshot for that reason rather than as a re-link (codex P2, cubic).
• A throwing derivation settles derive-failed instead of rejecting the resolver's await (cubic).
• The re-link guard runs only when a redirect is about to be returned (kilo).
• Stale dbt-adapter attempts no longer publish over a newer attempt's cache; tryExecuteViaDbt uses the adapter it was handed (CodeRabbit, cubic).
• The drift warning covers every warehouse capability shape (cubic).
• schema_inspect validates before it consults precedence, via a shared input-validation module with sql_explain (cubic).
• The guard-order test restores ALTIMATE_INTEGRATIONS (CodeRabbit, cubic).

Declined — per-integration capability gating (cubic): shadowing is keyed on the materialised key by design, which the consensus review named as the correct property; resolveDefaultTarget building the adapter (cubic): it mirrors the handler's own resolution and is single-flight once per process; recorded as a follow-up for when the dbt-first path is revived.

Runs: targeted suites 525 pass / 0 fail; bun test test/altimate/ 4423 pass, 1 fail = the pre-existing Trace.finalizeSync mtime flake; tsgo --noEmit clean. This push is a normal (non-force) commit on top of ae3fd152f.

@codex review against the numbered claims and the disclosed residuals in the review-log comment on this PR (and the attach contract it references): report only a reproducible trace that violates a numbered claim. Instances of the disclosed residuals are not findings. Since your round 2 on ae3fd152f, 6ab901fcd closes both findings — materialisation is filtered by the MCP client that served the key, and an unreadable link settles binding-unreadable with the reason in the result — plus: a throwing derivation settles derive-failed, the re-link guard runs only on the redirect path, dbt-adapter cache writes are ownership-guarded, the drift warning covers all warehouse capability shapes, and schema_inspect validates before precedence. A round with no claim violation ends review.

Residual addendum — from codex round 3 on 6ab901fcd

• R-P1 — later-step precedence derives from the live tool map while the turn's catalog is pinned. Precedence.refresh runs inside catalog() on every model step; pinTurnTools restores the turn's first engine wrappers after it. If another session's boundary replaces the shared engine mid-turn (attach contract R2), a later step derives precedence from the new engine's tools while the model still holds the first catalog's wrappers. The redirect then names a key whose pinned wrapper points at the closed client, so the call fails — it does not run on the other workspace — and the next turn boundary re-derives both. Closing it cleanly means retaining the turn's first precedence snapshot with the pinned catalog (turn state threaded through resolveTools) and, for attribution to refuse the case outright, identity on the attached outcome (attach log R19). Both belong to the lease work that is the GA gate.

Codex round 3 otherwise raised nothing; per the review policy this closes the codex rounds on this PR.

CodeRabbit's outside-diff item on precedence.ts (a stale announcement completion overwriting a recreated session's record) is fixed in a690b08dd: the completion guard now requires the stored snapshot to be the one the attempt was published for (bySession.get(sessionID) === result). Test: "a line delivered after its session was evicted and recreated does not overwrite the new record" — it fails with the previous has() guard.

@codex review — scoped round, on 915020f98. Do not re-review the PR. Verify or falsify one claim about the announcement bookkeeping in packages/opencode/src/altimate/workspace/precedence.ts (the completion guard if (delivered && bySession.get(sessionID) === result) announced.set(sessionID, attempt), introduced in a690b08dd):

Cubic asserts that two refresh calls for the same session while the first announcement is still in flight, deriving the same inventory line, leave announced empty after delivery — because the second refresh replaced the stored snapshot object, so the identity check fails — and the next turn re-announces the same line. Give a concrete trace with the exact sequence of refresh/delivery events and the state of publishing/announced at each step showing either the repeat or why it cannot happen. If it holds, also state whether an eviction-generation token (captured at publish time, invalidated only when the session is evicted from bySession) would close both this case and the original one the identity check was added for (a stale completion writing over a session evicted and recreated mid-flight), or name a case it would miss.